Repository navigation
fix(rooms): say why a group cannot mix a friend's Bot with an unshared Bot of mine, and offer the way out - #321
Conversation
…d Bot of mine, and offer the way out
A group with a friend's Bot is projected to that friend's home (fanoutRoomLine
sends its lines and every sharing Bot's replies on; the friend's lines come
back into the room my Bots read), so a local Bot with no grant to that friend
stays refused. The refusal was a bare rule ('Only a Bot you granted ...') and a
dead end. It now names the Bot and the friend, carries details for the client,
and the new-chat screen offers the Bot's invite link or leaving it out.
Nothing is granted by the click.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e0f074b02a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| await navigator.clipboard?.writeText(link) | ||
| setFixNote(t('Invite link for {name} copied. Send it to your friend; once they accept, create the group again.', { name: bot.name })) |
There was a problem hiding this comment.
Treat an unavailable clipboard as a copy failure
In an insecure context or locked-down WebView where navigator.clipboard is undefined, optional chaining makes this await complete successfully, so the UI claims the invite link was copied even though the clipboard was unchanged. Because this card does not display the newly minted link anywhere, the user cannot send that invite; check for clipboard.writeText explicitly and show the failure or link fallback instead of the copied message.
Useful? React with 👍 / 👎.
|
Maintenance review at tip e0f074b: design-consistent (no auto-grant, per-Bot grants kept, the refusal now names the Bot/friend and offers the invite or leave-out; English UI + zh). CI green, mergeable, verify green locally on top of current main. One open item, Codex's P2 on |
…ead of claiming it was copied Codex review on ThinkFlowLab#321: with no navigator.clipboard (insecure context, locked-down WebView) the optional-chained await resolved and the card said 'copied' while the link, minted for this click, was shown nowhere. Now a missing API or a refused write puts the link itself in the note (wrapping, selectable).
…ok it, else show it to copy by hand (ThinkFlowLab#330) Follow-up to ThinkFlowLab#321 (Codex P2 on new-chat.js: a missing or failed clipboard counted as a copy). Ran ARCH_DOCS_BASE=origin/main TZ=UTC npm run verify at the tip. Co-authored-by: Danyang Chen <15378933+Birfy@users.noreply.github.com>
A group that holds a friend's Bot (e.g. Yi's) and one of my own Bots that is not shared with that friend ends in a bare red line: "Only a Bot you granted (or one that joined with the room code) may be in a room with friends' Bots". That line says nothing about which Bot, which friend or what to do.
Root cause
room-membership.js(REMOTE_ROOM_MESSAGE, raised byapplyParticipantsat create,addRoomParticipantfor both directions). The rule is not a leftover: a group with a friend's Bot is relayed to the friend's home.fanoutRoomLinesends the group's lines on, and the replies of every local Bot thatmayShareRoom; the friend's Bot's lines come back into the room my Bots read;notifyRoomShareprojects the room to their home. A local Bot with no grant to that friend would be silently cut off from them (its lines are filtered) while reading their text, and Bot Social would refuse its sends anyway (the grant lives on the server and exists only after the friend accepts an invite to that Bot). The screenshot case: the only local Bot (程序员) has no grant to Yi.Behaviour chosen
error.details = { reason: 'ungranted-local', bots, remotes }(channelfailforwards a plain-objectdetails; clientapi.jsputs it on the error).__flybot__.social.createInvite; the friend's accept is what creates the grant, so nothing is granted by the click) and Leave {Bot} out. ZH strings added.Verification (tip e0f074b, Node 24.21.0)
ARCH_DOCS_BASE=upstream/main TZ=UTC npm run verify: exit 0 (core 848, social 212, tree 56, timeline 80, interop and live-e2e green);ds-bot-patches checkok, ds-bot pristine at pin 2b10c70.upstream/main+ only the test files): 9 fail; green at tip.